LookerのコンテンツをCLIでデプロイ可能な”Looker Deployer”を試してみた #looker

「カスタマーストーリー」を支えるツール特集

#Looker

さがら

2021.02.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

さがらです。

Lookerは基本SaaSとして提供され、ブラウザ上のGUIから操作するBIツールです。

なのですが、オープンソースでCLIツールが提供されているのをご存知でしょうか？例えば、Gazer、Looker Deployer、Henryと言ったツールがあります。

本ブログではこのCLIツールのうち、Looker Deployerを試してみましたので、その内容をまとめてみます。

Looker Deployerとは

Looker Deployerは、Lookerオブジェクトをインスタンス間で移動＆コピーさせるためのCLIツールです。例えば、Look、Dashboard、folder、Connection、Boards、に対応しています。

Looker Deployer (aka 'ldeploy') is a command line tool to help move Looker objects across instances. This includes Content (Looks, Dashboards, entire Spaces, etc.), Boards and Connections.

主な用途としては、「開発環境のインスタンス➟本番環境のインスタンスにダッシュボード等のコンテンツをデプロイする」ことになるかと思います。

インストールや使い方は下記のURL上にまとまっていますので、ぜひこちらも御覧ください。

実施環境

WSL2上のUbuntuで実施しました。

ポイントとしては、Gazerも入れてあげる必要があります。以下、公式DocのRequirementより必要な理由を抜粋してます。

Gazer : The content deployment command makes use of gzr to automate content deployment, so you will need to have that installed and configured properly. Gazer requires an up-to-date version of ruby.

Gazerとは、LookerDeployerと同様にコマンドでLooker上のオブジェクトの管理・操作を行える、RubyベースのOSSのCLIツールです。

GazerはRubyで開発されているので、Rubyも入れておく必要があります。

Windows
- エディション：Windows 10 Pro
- バージョン：20H2
- OSビルド：19042.804
Ubuntu
- バージョン：20.04 LTS
Ruby関係
- Ruby 2.7.0
- gem 3.1.2
- Gazer 0.2.44
Python関係(pyenv + venv使用)
- Python 3.8.5
- Looker Deployer 0.3.0

セットアップ

インストール

インストールは簡単で、pip install looker-deployerを実行するだけでOKです。

もし下図のようにエラーが発生した際には、pip install --upgrade pipを実行して、pipのバージョン更新を行いましょう。

接続情報の定義ファイル作成

Looker Deployerを使用する作業ディレクトリ上で、looker.iniという接続情報を定義するファイルを作成します。（もし何かしらの事情で別ディレクトリに作成したい場合には、コマンド実行時に--ini [任意のパス]/looker.iniとオプションを加えて実行してあげればOKです。）

この例では、[dev]を開発環境、[prod]を本番環境と想定して設定しています。dev、prod以外の名前でも問題ありませんが、Looker Deployerのコマンドを実行する際に指定する名称になりますので、長い名称や半角スペースを入れるなどは避けた方が良いと思います。

[dev]
base_url=https://[開発環境のLookerインスタンスのAPI Host URL]:[port]
client_id=[開発環境で使用したいユーザーのAPI3 keysのClient ID]
client_secret=[開発環境で使用したいユーザーのAPI3 keysのClient Secret]
verify_ssl=True

[prod]
base_url=https://[本番環境のLookerインスタンスのAPI Host URL]:[port]
client_id=[本番環境で使用したいユーザーのAPI3 keysのClient ID]
client_secret=[本番環境で使用したいユーザーのAPI3 keysのClient Secret]
verify_ssl=True

この設定において、base_urlの内容を記述する際2点躓いた点があったのでここに記します。

LookerインスタンスのAPI Host URL

「Lookerログイン➟Adminタブ➟API」から確認することが出来るAPI Host URLの内容を記述します。

もし、空白の場合には対象のインスタンスのドメイン部分(`https://~~~.jp.looker.com`)を記述します。

port番号

base_urlの末尾にはport番号を記述します。しかし公式Docには「19999」の事例しか記載されていない上、このpord番号では起動せず戸惑いました…

色々検証した結果、こちらの公式Docに従ってport番号を「443」に変更した所、上手く実行する事ができました。

Looker APIのデフォルトのport番号については、以下のように考えてもらえばOKです。

Looker APIのデフォルトportが「443」の場合
- 対象のインスタンスがGCPにホストされている
- 対象のインスタンスがAWSにホストされていて、かつ「2020年7月7日以降」に作られている
Looker APIのデフォルトportが「19999」の場合
- 対象のインスタンスがAWSにホストされていて、かつ「2020年7月6日以前」に作られている

設定サンプル

これらに注意した後、全て公開することは出来ませんが、私のlooker.iniは以下のような内容になりました。

試してみた

各コマンドのhelpの確認

Looker Deployerの各コマンドごとに--helpを加えて実行することで、各コマンドの使い方がズラッと表示されます。

ldepoy --help # ldeployに関する、サブコマンドやオプションを表示
ldeploy [サブコマンド名] --help # ldeployの指定したサブコマンドに関する、サブコマンドやオプションを表示

コンテンツのデプロイ

「Looker Deployer」という名前の通り、主要機能であるコンテンツのデプロイを試します。

残念ながらインスタンスを2つ用意出来ないため、1つのインスタンス内で「開発環境想定フォルダ」➟「本番環境想定フォルダ」へコンテンツをまとめてデプロイする、ということを実施してみます。

開発環境想定フォルダ

開発環境想定フォルダは、使用するインスタンス内の私の個人フォルダ内にDevelopmentというフォルダを作りました。

Developmentフォルダの中にダッシュボード1つ、Dev_childという子フォルダを作っています。 Dev_childの中にもダッシュボードを1つ作っています。

下図赤枠内の、URLの末尾の番号がこのフォルダに割り振られたユニークなIDになるのですが、このIDがコマンドを実行するときに必要となりますので、覚えておいてください。

本番環境想定フォルダ

本番環境想定フォルダは、使用するインスタンス内のSharedフォルダ内にShared/Deployer_test/Productionという階層構造でProductionというフォルダを作りました。

下図赤枠内でも囲んでいますが、デプロイ先のフォルダへのパス情報Shared/Deployer_test/Productionがコマンドを実行するときに必要となりますので、覚えておいてください。

手順1.開発環境からコンテンツ情報のexport

以下の内容でコマンドを実行します。

--local-targetで指定する「コンテンツ情報をexportするディレクトリ名」は、その名前でディレクトリが存在しない場合は自動で作成してくれる仕様となっています。

ldeploy content export \
--env [looker.iniで定義した開発環境の接続情報の名称] \
--folders [開発環境にあるデプロイしたいフォルダのID] \
--local-target [コンテンツ情報をexportするディレクトリ名]

状況に応じて、他にもオプションがありますので付け加えてください。

以下、私が実際に実行したコマンドと実行後の様子を記します。

ldeploy content export --env dev --folders 81 --local-target deploy_contents

コマンドを実行したLookerインスタンス上のフォルダの階層に基づいてツリー構造でディレクトリが作られ、ダッシュボードやフォルダの定義情報はjson形式で所定の場所に作成されます。

参考までに、ダッシュボードの定義ファイルと実際のダッシュボードをまとめたサンプルの画像を以下に載せておきます。

手順2.本番環境にexportしたコンテンツ情報をimport

以下の内容でコマンドを実行します。

--recursiveオプションを入れることで、--foldersオプションで指定したディレクトリ内に子フォルダがあってもまとめてデプロイしてくれます。

ldeploy content import \
--env [looker.iniで定義した本番環境の接続情報の名称] \
--folders [デプロイしたいディレクトリ名　※先程exportした情報を元に] \
--recursive \
--target-folder [デプロイ先となる本番環境のフォルダパス] \

状況に応じて、他にもオプションがありますので付け加えてください。

以下、私が実際に実行したコマンドを記します。

実運用を想定して1点工夫しているのですが、--foldersオプションには先程exportしたディレクトリ名であるdeploy_contentsではなく、Developmentディレクトリまでのパスを指定しています。これにより、UsersやSatoshi Sagaraと言った、不要なフォルダ階層が本番環境に作られることを避けることが出来ます。

ldeploy content import --env prod --folders "./deploy_contents/Users/Satoshi Sagara/Development" --recursive --target-folder Shared/Deployer_test/Production

以下、コマンド実行後の様子と、デプロイ後のProductionフォルダの内容の図となります。

開発環境想定のDevelopmentフォルダと同じ構成で、子フォルダやダッシュボードが作られていることがわかるかと思います。